Enterprises are increasingly being asked to provide access to proprietary applications and data to employees and partners located outside the perimeter of the enterprise network. To do so in a cost-effective manner, enterprises are looking to leverage public networks such as the Internet for providing remote access. However, because the Internet is a publicly accessible network, issues of network security arise.
Multiple technologies are available for accomplishing secure Internet communications, including but not limited to those that rely on Secure Sockets Layer (SSL) encryption or Internet Protocol Security (IPSec) encryption. SSL encryption is incorporated into most Web browsers utilized by today's Internet users while IPSec presently is not.
SSL technology is limited, however, in its ability to provide remote access to a private network in that an SSL-encrypted client cannot directly access Domain Name Servers, Windows Internet Naming Service (WINS) Servers, or other resources on a private network that are not visible from outside the enterprise network but are essential to reaching resources on that network. In addition, firewalls typically block certain traffic through various ports and limit access to various Internet Protocol (IP) addresses automatically, thereby preventing SSL-encrypted clients from accessing certain destinations on the enterprise network. Finally, important applications such as various client-server e-mail programs and other enterprise application programs do not support SSL encryption natively and so limit the effectiveness of SSL in providing secure remote access to these resources.
Virtual private network (VPN) connections allow remote users and client programs (in other words, those that are not directly connected) to achieve encrypted remote access to a private data network via public internetworks (such as the Internet). Conventional approaches to setting up a VPN have included setting up remote access using pre-installed “thick clients” that are based on the IPSec standard or SSL and earlier versions of Web browser-based dynamic SSL VPN technology. Each is explained in more detail below.
VPN thick clients based on IPSec technology involve the transmission of whole packets over the Internet in encrypted form. Though robust and secure, IPSec technology has significant limitations. These limitations include, among other things, the administrative challenges in rolling out, managing, and maintaining the VPN client software for remote access users because every user must download and install the IPSec software on his or her computer. In addition, utilizing IPSec VPN technology, users cannot access key resources from alternate endpoints (in other words, any device on which the user has not installed the relevant software). Furthermore, user access to sites protected by firewalls is limited or, in some cases, nonexistent.
A conventional SSL version of the thick client avoids the firewall limitations of the IPSec thick client by using a standard SSL port that firewalls generally keep open. However, such an implementation still incurs the disadvantages of having to have the client software pre-installed from wherever the access takes place. These disadvantages include management complexity and the inability to provide access from any client computer equipped with a standard Web browser without the need for installing special software.
A conventional dynamic port proxy approach preserves the firewall traversing capabilities of an SSL thick client, and addresses the limitations of both IPSec and SSL thick clients by utilizing the built-in encryption capabilities of a Web browser, thereby obviating the need for installing special client software. In accordance with such an approach, a gateway device or program on an access server downloads a Java applet to monitor ports for encrypted traffic. If encrypted traffic is detected, the client sending the encrypted data is configured to re-direct its traffic through an applicable secure port. The problem with this technique, however, is that it works only for addresses that have names. In other words, it will not work with a static IP address or where the IP address and/or port of a server dynamically changes. Therefore, these implementations cannot handle applications that use dynamically assigned IP addresses, dynamically change ports, or use hardcoded IP addresses to reach unnamed resources.
What is desired, then, is a system and method for providing secure remote access to applications and data in an enterprise network over a public data communication network, such as the Internet, that improves upon and addresses the aforementioned shortcomings of conventional solutions.